home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 22
/
Cream of the Crop 22.iso
/
program
/
tdk_v120.zip
/
DOORKIT.DOC
< prev
next >
Wrap
Text File
|
1996-07-23
|
16KB
|
271 lines
───────────────────────────────────────────────────────────────────────────────
▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀
▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀ ▀▀▀ ▀▀▀▀▀ The DoorKit!
▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀
The BBS Door Development Kit By The People - For The People!
───────────────────────────────────────────────────────────────────────────────
The ANSI/ASCII/RIP/MAX DoorKit v1.20
No Copyright Notices Expressed Or Implied
Compiled By Larry L. Athey From Numerous Sources
───────────────────────────────────────────────────────────────────────────────
NOTE: The DoorKit! requires you to have Turbo Pascal 7.0 or Borland Pascal
7.0 With Objects. Certain compiler directives in these units are not
campatible with Turbo Pascal 6.0....If you have Turbo Pascal 6.0 you
will have to make a number of modifications to this kit. Sorry, but
since I don't use TP6.0, I cannot assist you with any modifications.
Welcome to The DoorKit!
───────────────────────
This is a compilation of various procedures and functions by various authors
structured in such a way that I believe makes one of the most powerful BBS
door development kits available. The reason for me making this kit is because
out of all the door development kits out there I've tried (with source code)
they all fall short in one way or another. So what I have done is take all
of the the best features of numerous door kits, various source code samples
from SWAG, plus procedures I have written myself, and compiled one big door
development kit.
If you are concerned with the legality of the methods used to develop this
kit, let's just say (for the sake of legal matters) that this kit is really
a "Parody" on other people's kits. Really, it's a parody.....I just have a
crappy sense of humor when it comes to programming. Parodies are legal and
cannot go hand in hand with plagiarism. Just ask Weird Al Yankovich.... :)
If you are still concerned at this point, just look at it like this: Every
major door development kit out there does the same thing, the difference is
I'm admitting to the use of other people's code whereas they are not. Still
the code used in this kit has been completely modified to make it work hand
in hand with the rest of the kit, so none of these derivitives are any way
comparable to their original sources.
I am by no means taking credit for this kit, all of the authors of the door
kits and SWAG contributors did all of the real work. All I did is make some
modifications, debugging, and repackage the procedures and functions in here.
Make note that all of these kits that I used parts from plainly state that
I cannot make another kit using their source that I intend to sell. This is
why there is no price tag on this kit. These people donated their source to
the public and I am doing the same thing with my source as well.
By no means am I trying to tell you that this is The Best door kit in the
world. I am sure that you can find others out there that will run circles
around this one. The only reason I am plugging this kit is because this is
the one that I use in my doors and I get literally TONS of compliments on
my doors. One thing you will probably not like about this kit is that the
constants and variables used in it take up about 9.5K of your data segment.
I know, I could have made it take up much less, but the only way I could do
that is to use pointers. Unfortunately, there are a lot of programmers out
there that think pointers are the work of Satan himself. So in the spirit
lazy programming techniques, you will lose 9.5K of your data segment with
this kit. However, you can modify this at your own discretion so that the
kit won't eat up as much memory. To tell you the truth, other door kits I
have tried eat up about the same amount or more.
Another thing you may notice is that there is no support for the door game
L.O.R.D. and no other Inter-BBS games. I don't play door games and neither
do the users on my BBS. If the opposite was true, then I would know about
this kind of stuff. As it stands, I don't know squat about it so there is
no way I can support it. But still, since this kit contains full source
code, you are free to add it. If you do, please send me all of the source
and other information needed so I can update The DoorKit archive.
Do with this kit what you will....All I ask is if you find a better way of
doing something (which you will), please send me a copy of what you did so
that I can update future versions of this kit. Plus it will help me learn
more about the way other people work. My code bores me, I like looking at
other people's code to learn new tricks. I will also add your name to the
list shown below so you are given full credit for your work.
───────────────────────────────────────────────────────────────────────────────
Basic Features:
───────────────
-Autodetects the caller's graphics rather than relying on drop file info.
-Supports ANSI/AVATAR/TTY/RIP/MAX graphics (See MAXINFO.DOC).
-Supports DOOR.SYS and DORINFOx.DEF drop files.
-Full error trapping and logging of expected & unexpected errors.
-Full monitoring of carrier dropping and user inactivity time-outs.
-Uses a "Virtual Screen" for all local screen drawing.
-DOS, Double-Dos, DesqView, Windows, OS/2, and Novell Netware friendly.
-Built in highly optimized Pascal 'EXEC' replacement.
-Only leaves a 1.2K footprint in memory when swapped out.
-Automatic swapping to EMS -> XMS -> Disk.
-Supports Fossil and UART communications routines.
-Full support for non-standard port and IRQ settings.
-All door serial I/O settings are fully configurable.
-Program startup/initialization streamlined into one InitDoorKit command.
-Automatic handling of all program exit processes.
-Uses typed control files rather than text based INI files.
-Includes a freeware control file editor to distribute with your doors.
-Easily definable sysop "F-Keys", no Far Calls needed for these functions.
-Easily definable command line parameters.
-Full support for local and remote Cursor, Home, End, and Delete keys.
-Built in split screen and line by line chat modes.
-Numerous cosmetic procedures already written into the package.
-Numerous string handling procedures already written into the package.
-Numerous file handling procedures already written into the package.
-Built in questionnaire/script language.
-Built in online text file reader procedure.
-Supports inline color tokens for coloring text files.
-Library of global system variable tokens for use in screen/text files.
-Includes procedures for full activity and error logging.
───────────────────────────────────────────────────────────────────────────────
Technical Information:
──────────────────────
Sorry, this isn't going to be very extensive. The units included in this
package are commented pretty well, so there won't be a whole hell of a lot
documentation. Sorry about that, but if somebody else out there wants to
write complete documentation for it.....Have at it! I'm sure others will
probably thank you for it.....I really don't see the lack of documentation
being a problem since there has been this world-wide campaign initiated to
abolish the reading of documentation. All you techno-jocks will just have
to "Make-Due" with the code comments..... ;) If you don't bother to read
the comments in each unit, then you are not going to know about all of the
possibilities you have at hand. So please....READ!
Door Initialization:
────────────────────
The DoorKit uses binary, or "Typed" files for storing the configuration for
each node. The naming convention for these "Control Files" is NODE###.CTL
with the ### representing the current node number. I have included a little
utility for creating/editing these control files. You may package this in
your doors, or you may write your own configuration routines to handle it.
The program MAKECTL.EXE is the control file editor. You simply execute it
with the node number on the command line to tell the program which node you
wish to create or edit the control file for. You may also wish to write a
procedure to read text based control files. I don't like text files because
they just slow down a program. A typed file is just a one shot open, read,
and close. Whereas text files always require you to read a line, translate
it into data the door can use, and repeat the process until you have all of
your critical variables set. (Can we say: Sloooooowwwww?)
ANSI Screen Files:
──────────────────
I'll say it right now, you may find a better way to handle ANSI screen files
than I have. With the current design, you must save your ANSI screen files
with a maximum of 128 characters per line. I don't know how other drawing
programs work, but with "TheDraw" you are prompted to enter the max width of
the screen file before you save it. Simply set this to 128 characters and
procedure with the saving process. The reason this kit requires screens to
be saved like this is because of the way screens are translated. Each line
of the screen file is read and then checked for global system variables and
translated if they are found. Well, don't ask me why, but something somehow
gets lost in the translation. Saving the screens 128 characters wide fixes
the problem for some reason. If you can find a way around it, please let me
know how you did it....You may also want to note that ANSI screen files use
direct video writing rather than BIOS writes. This results in a much faster
displaying of screens on the local side. (See ANSIUNIT.PAS)
Shutting Down Your Door:
────────────────────────
There is no need to call any special procedure to shut down The DoorKit at
the end of your program. If you look at the _EXIT.PAS unit, you will notice
that there is automatic error handling in this kit. Even if your door exits
with a runtime error, all of the required exit processes will be taken care
of for you. You can add steps to the exit process with AddToExitChain. Just
read the comments in the _EXIT.PAS unit and you'll see how simplified the
exit or shutdown process is. What's more is if your program bails out with
a runtime error, a detailed description of the error is written to an error
log file. Believe me, this _EXIT.PAS is a lifesaver of a unit!
───────────────────────────────────────────────────────────────────────────────
Credits:
────────
Bob Dalton - The DDPLUS development library. A very nice kit and the
first one I ever used, unfortunately the author(s) didn't
plan ahead with the kit. If you wanted to write any kind
of a program where you wanted to control the cursor with
your arrow keys you were screwed. You would almost have
to completely rewrite the DDPLUS.PAS unit to do it. This
is still a really nice and well documented kit, it's just
kinda limited in its native design.
John Stephenson - The JSDoor development library. I would say that 40% of
this kit was created using portions of the JSDoor kit. I
would have just stayed with JSDoor, but there were just
too many bugs in it. With the way that JSDoor is designed
it makes it almost impossible to track down problems in
it unless you were the one that wrote it. There are some
serious problems in it's time keeping method and the way
it handles sysop keys. The split screen chat is screwed
up too, but since it's too "Spaghetti-ish" it's just too
wierd to fix. Too bad....
Jason Morriss - The COMMIO development library. COMMIO is (as this kit is)
a compilation of other people's source as well as his own.
I noticed his serial communications routines came from the
DDPLUS door development kit which are the same ones as I
used in here. However, these units have been modified in
a big way. As with JSDoor, this is another one of those
kits that has a lot of bugs in it and since its structure
was so weird, it was simply too difficult to fix it....
SWAG Support - The SourceWare Archival Group. A HUGE amount of code in
this kit came from SWAG. Since there are too many people
to name, I will simply pay credit to "SWAG" here.
Thomas Wagner - The EXEC.PAS unit and supporting files. This is a great
unit specifically designed to replace the EXEC command in
Pascal. The unit has built in memory swapping and when
you execute a child process or drop to DOS, only a 1.2K
foot print is left in memory thus giving the most free
memory to run external programs.
Dorinda D Hayek - Major contribution to the MAX Graphics development kit
and made a number of changes in TDK v1.10 to optimize
performance and enhance features. Her contribution to
TDK v1.10 made the quick release of v1.20 possible.
Larry L. Athey - The structure of TDK, ANSIUNIT.PAS unit, numerous complex
procedures, numerous "Artsy/Fartsy" procedures, and the
concept of the MAX graphics protocol and development kit.
Anybody Else? - If there is a chance that I'm using code in this kit from
anybody I neglected to mention, sorry about that. Let me
know and tell me what portion of the code it is that you
are the author of and I'll add your name to the list.
───────────────────────────────────────────────────────────────────────────────
But What About MAX?
───────────────────
The MAX Graphics haven't been implemented yet. I'm waiting to make sure The
DoorKit will work fine on its own as an ANSI/ASCII/RIP kit first. After I
am positive that everything is solid, then the MAX Graphics will be added.
I am still testing MAXterm on my system and I am happy to say that all is
well. It's just a matter of finishing up the script language and animation
commands for the door interface. For more information on MAX Graphics, see
the file MAXINFO.DOC.....
───────────────────────────────────────────────────────────────────────────────
What's New?
───────────
Arrrggghhh....Man, there are way too many things to list and I honestly
couldn't tell you anyway. All I can say is that a real sharp programmer
in Longmont, Colorado got ahold of TDK and enhanced the hell out of it!
Major thanks to Dorinda D. Hayek, she's one hell of a programmer!
───────────────────────────────────────────────────────────────────────────────
Larry L. Athey
1239 Cheyenne
Alliance, NE, 69301
Owner : BBS Utiliteez Software
FAX/BBS #: (308)762-2239
FidoNet : 1:285/703
GDS-Net : 100:1010/1
ivNET : 411:1500/0
Internet : larry.athey@tos.daphnis.com, larry.athey%otherside@ivsoft.com